1. Field
The present description relates to a method, system, and computer program product for automated deployment of software for managed hardware in a storage area network.
2. Description of Related Art
A storage area network (SAN) is frequently used to couple remote computer storage devices such as disk arrays, tape libraries, optical jukeboxes or other storage devices, to hosts in a manner which permits the storage devices to appear to the operating systems of the hosts as locally attached to the hosts. The storage area network may include a storage controller which may have multiple servers often referred to as a cluster of servers, which receive input/output (I/O) requests from one or more hosts, to perform input/output operations in which data is read from or written to storage through various I/O adapters. Each cluster may have one or more central processing units (CPUs) in which the processing and memory resources of the cluster may be apportioned into logical partitions, often referred to as a “virtual server,” each of which is capable of running an operating system and performing the functions of a “server”. Thus, as used herein, the term “server” may be used to refer to a physical server or a logical partition or virtual server performing a server function.
A server may have multiple I/O adapters including host and device adapters which are accessed through a switch such as a PCIe switch, for example. To increase efficiency, it is often desirable to share I/O adapters amongst the servers of the cluster. Thus, a device adapter, for example, may be shared as a “virtual” device adapter. The servers typically communicate with the device adapters and other I/O adapters over a “fabric” which may comprise one or more interfaces providing communication paths between the servers and adapters.
The fabric may include one or more switches which permit the I/O adapters to be shared by the servers. Each switch typically includes routing logic which logically couples a selected upstream port of the switch to a selected downstream port of the switch. In this manner, a particular server coupled to an upstream port, may be logically coupled to a particular device adapter coupled to a downstream port, for the purpose of conducting I/O operations between that server and storage via the device adapter. Similarly, a particular server coupled to an upstream port, may be logically coupled to a particular host coupled to a downstream port, for the purpose of conducting I/O operations between that server and host via the host adapter.
Thus, each server may be logically coupled to each I/O adapter of the shared adapters via the switch. Each switch typically further includes error reporting logic. In the course of an I/O operation, an error may be detected by the switch or one or more of the shared I/O or host adapters. The switch is configured or programmed to report the occurrence of an error via the “transparent” upstream port which is the upstream port connected to the root server for the switch and the shared I/O adapters coupled to the switch. The various devices of the storage area network may be managed by one or more users utilizing a systems manager which includes hardware and software and provides a suitable user interface. An example of systems manager software is the IBM Systems Director which can facilitate managing both physical and virtual systems across a multi-system environment which can include hardware and software from a variety of different vendors.
From a suitable access point such a browser, a systems manager permits a user to monitor system environmentals, resources, inventory, events, task management, core corrective actions, distributed commands, and hardware control for both servers and storage. The systems manager can provide views for visualizing managed systems and to assist the user in determining how these systems relate to one another while identifying their individual status.
Systems managers frequently use industry standards such as the Common Information Model (CIM), which is an industry standard for managing systems. CIM was designed to be used for describing management information between differing management applications, running in many different operating environments, including Microsoft Windows and Linux. CIM provides a common definition of management information for systems, networks, applications, and services, and allows for vendor extensions. CIM common definitions enable vendors to exchange rich management information between systems throughout the network. CIM is composed of a specification and a schema. The schema provides the actual model descriptions, while the specification defines the details for integration with other management models.
Another industry standard often utilized by a systems manager is the Storage Management Initiative Specification (SMI-S), which is an industry standard for accessing and managing individual storage devices including RAID controllers, disk storage devices, SAN switches, etc. SMI-S defines a method for the interoperable management of a heterogeneous storage area network (SAN). SMI-S expands on the CIM standards, using Extensible Markup Language (XML) over hypertext transfer protocol (HTTP) to communicate between storage management applications and the devices that they manage. The specification standardizes and streamlines storage management functions and features into a common set of tools that address the day-to-day tasks of the information technology environment. Common systems management functionality such as discovery, inventory, system configuration, and event notification can be achieved using the SMI-S standard.
Accordingly, to manage the individual devices of the SAN, a systems manager will communicate with a provider module often referred to as an “SMI-S provider” which is often vendor-specific software although compliant with the SMI-S standard. The SMI-S provider module is used so that independent systems manager software, such as IBM Systems Director, can manage a vendor device using a standard interface based on the industry standard Common Information Model (CIM) protocol.
A user typically manually installs and configures an SMI-S provider module on a remote server. Once installed, the SMI-S provider module can further be configured through an interface provided to the user by the systems manager. The configuration typically includes details relating to the specific device being added to the SAN. Thus, configuration may include manually inputting security configuration (such as password credentials, for example), network configuration data (such as the IP address) of the device.
Some SMI-S provider modules can manage more than one device. Thus, if the device being managed is a storage array controller, for example, as more storage array controllers are added to the network, the SMI-S provider module already installed for those types of storage array controllers may be manually configured each time a storage array controller compatible with that SMI-S provider module is added to the network. However, SMI-S provider modules typically have a limit on the number of devices which any one SMI-S provider module can manage.
Hence, when adding a new device to the network, the user frequently needs to determine if any installed SMI-S provider module is suitable for the device to be added and if so, whether configuring the compatible SMI-S provider module for the new device will exceed the limitation placed on the total number of devices which may be managed by that particular SMI-S provider module. The limit on the number of devices per SMI-S provider module can vary from vendor to vendor. If the new device will exceed the limit of devices for the installed SMI-S provider module compatible with the new device, an additional suitable SMI-S provider module may be manually installed and manually configured for the new device.
Also, the systems manager software may have restrictions on the level or version of provider module that is supported by the systems manager software. Accordingly, before a provider module is installed, the user may need to upgrade the level or version of the provider module. This process typically involves the user identifying the correct provider module that is both compatible with the firmware version of the device being added to the network, as well as compatible with the systems manager software.
Still further, the user using the interface provided by the systems manager, may determine that a suitable server for hosting installation of the new provider module is not available. Hence, the user may need to manually reallocate additional resources to an existing server or manually deploy another server such as a virtual server to host the new provider module, again using the interface provided by the systems manager. If a new server is deployed, the user typically manually installs an operating system on the new server and manually allocates sufficient resources to the new server to accommodate the new provider module once it is manually installed on the new server and configured by the user.